Methods, devices and systems for preventing tracking by use of reply attacks

ABSTRACT

A method can include establishing a wireless encrypted connection; establishing a long term encryption key (LTK) and an anti-tracking (A-T) count value for a peer device; storing the LTK and A-T count value in a nonvolatile memory circuit; receiving a communication that includes an identity value corresponding to the peer device and a peer hashed anti-tracking count (HATC); generating at least one local HATC by executing a predetermined hash function on at least the LTK and a changed A-T count value that varies from the stored A-T count value by a predetermined amount. The received peer HATC can be authenticated with the at least one local HATC. In response to the peer HATC being authenticated, communications can occur with the peer device. In response to the peer HATC not being authenticated, communications may not occur with the peer device. Related devices and systems are also disclosed.

TECHNICAL FIELD

The present disclosure relates generally to wireless devices thatinclude secure identity keys for identifying peers, and moreparticularly to preventing tracking of such wireless devices through theuse of replay attacks.

BACKGROUND

Devices operating according to a Bluetooth (BT) standard can useresolvable private addresses (RPAs) to identify peer devices. BT devicescan pair with another, exchange security information, and afterestablishing an encrypted connection with temporary keys, bond with oneanother. Bonding can include the exchange long term values, includinglong term encryption keys (LTKs) and identity resolving keys (IRK). Oncebonded, BT devices can establish an encrypted connection without havingto exchange security information by identifying one another by usingRPAs. FIG. 12A shows an RPA. An RPA can include a 24-bit hash value anda 22-bit randomized value (prand), and two fixed bits “1” and “0”. Thehash value can be generated by hashing with the IRK and the prand value.In this way, BT devices receiving requests from an apparent peer, canhash a prand included in the message with stored IRKs to resolve theaddress and thus identify the peer.

A drawback to conventional operations is that it is possible to usereplay attacks to detect and track a device. FIGS. 12B-0 and 12B-1 showconventional operations of BT systems, including responses to a replayattack. FIG. 12B-0 shows a system 1251 at a first location. A firstlocation can include a BT peripheral device 1255 that has previouslybonded with a BT central device 1253. Peripheral device 1255 can issuean advertisement 1259 (shown by {circle around (1)}). Because thecentral device 1253 and peripheral device 1255 were previously bonded,advertisement can include an RPA generated with an IRK that is known bythe central device 1253. Upon receiving the advertisement 1259, centraldevice 1253 can resolve the RPA to confirm the identity of theperipheral device, and generate a response 1263 (shown by {circle around(2)}). However, a snooping device 1257 at the same location can detectthe advertisement 1259 and record its content, including the RPA 1261.

FIG. 12B-1 shows a system 1265 at a second location. While centraldevice 1253 is at the second location, a phishing device 1257′ can emita replay message 1259R that includes the RPA 1261. In response, centraldevice 1253 can resolve the address and issue a response 1263′. Fromsuch a response, the central device 1253 can be tracked at the secondlocation, particularly if the central device 1253 is the only otherdevice at the second location.

Other conventional systems can suffer from the same or similar drawbacksnoted in FIGS. 12A to 12B-1 . For example, a neighbor-aware-network(NAN) can use identity tags to authenticate devices that have previouslyexchanged or derived identity keys. In particular, a WiFi Aware networkcan operate with NAN identity resolution (NIR) values. NIR values caninclude an NIR tag generated as follows:

NIR Tag=Truncate-64(HMAC-SHA-256(NIK, “NIR”, NMI∥Nonce∥counter),

where Truncate-64 is a 64-bit truncation operation, HMAC-SHA-256 is ahash function, NIK is a NAN identity key previously established in apairing setup operation, NMI is a NAN management interface address,Nonce is a nonce value, and counter is a counter value.

FIG. 13A shows operations of a NAN system 1351 at a first location. Afirst location can include a subscriber device 1355 that has previouslyexecuted a pairing setup operation with a publisher device 1353.

Subscriber device 1355 can issue a subscriber message 1367 with an NIRtag (NIR_s). Publisher device 1353 can resolve NIR_s using a stored NIKfor the subscriber device. Similarly, publisher device 1353 can issue apublisher message 1359 with its own NIR tag (NIR_p 1361). Subscriberdevice 1355 can resolve NIR_p 1361 using a stored NIK from the publisherdevice. In this way, a subscriber device 1355 can discover a serviceinstance of the publisher device 1353 and the two devices can beestablished as being paired 1369.

Once subscriber device 1355 establishes that it is paired with publisherdevice 1353, it can start a pairing verification operation 1373. Pairingverification can include the exchange of messages in a pre-associationsecurity negotiation (PASN), including a first PASN message 1375. Whenpairing verification ends, subscriber device 1355 and publisher device1353 can setup an encrypted data path for communication.

Referring still to FIG. 13A, a snooping device 1357 can be at the firstlocation, and can record publisher message 1359, including NIR_p 1361.

FIG. 13B shows a system 1365 at a second location. While a subscriberdevice 1355 is at the second location, a phishing device 1357′ can emita replay message 1359R that includes the NIR_p 1361. In response,subscriber device 1355 can resolve the NIR tag 1361 and determine thephishing device is a paired device 1369′. Subscriber device 1355 canthen start a pairing verification operation 1373′. This can include thesubscriber device 1355 issuing a first PASN message 1375′. From such amessage, the subscriber device 1355 can be tracked 1379 at the secondlocation, particularly if subscriber device 1355 is the only otherdevice at the second location.

It would be desirable to arrive at some way addressing the trackingvulnerabilities of wireless systems described herein.

SUMMARY

Embodiments can include a method that establishes a wireless encryptedconnection; establishes a long term encryption key (LTK) and ananti-tracking (A-T) count value for a peer device; stores the LTK andA-T count value in a nonvolatile memory circuit; receives acommunication that includes an identity value corresponding to the peerdevice and includes a peer hashed anti-tracking counter (HATC). At leastone local HATC can be generated by executing a predetermined hashfunction on at least the LTK and a changed A-T count value. A changedA-T count value can vary from the stored A-T count value by apredetermined amount. The received peer HATC can be authenticated withat least one local HATC. In response to the peer HATC beingauthenticated, communications can occur with the peer device. Inresponse to the peer HATC not being authenticated, no communications aremade with the peer device.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a flow diagram of a method for a responding device accordingto an embodiment. FIG. 1B shows enhanced privacy values that can bestored by a device according to an embodiment.

FIG. 2 is a flow diagram of a method for a requesting device accordingto an embodiment.

FIG. 3 is a diagram showing a system and operations for Bluetooth (BT)devices according to an embodiment.

FIG. 4A is a diagram showing a set up operation forneighbor-aware-network (NAN) devices according to an embodiment. FIG. 4Bis a diagram showing a verification operation for NAN devices accordingto an embodiment.

FIG. 5 is a block diagram of a device having enhanced privacy accordingto an embodiment.

FIG. 6A is a block diagram of a BT device having enhanced privacyaccording to an embodiment. FIG. 6B is a diagram showing BT packetaccording to an embodiment.

FIG. 7A is a block diagram of a NAN device having enhanced privacyaccording to an embodiment. FIG. 7B is a diagram showing a NAN packetaccording to an embodiment.

FIG. 8 is a diagram of a device according to an embodiment.

FIG. 9 is a block diagram of system according to an embodiment.

FIG. 10 is a diagram of system according to another embodiment.

FIG. 11 is a diagram of a system according to a further embodiment.

FIGS. 12A to 12B-1 are diagrams showing conventional BT devices andresponses.

FIGS. 13A and 13B are diagrams showing conventional NAN devices andresponses.

DETAILED DESCRIPTION

Embodiments can provide enhanced privacy in wireless systems in whichdevices communicate directly with one another over encryptedconnections. Devices can establish initial encrypted connections andexchange protected data, which can include long term encryption keys(LTKs) as well as an anti-tracking (A-T) count value. When acommunication is received from what appears to be a peer device, it canbe authenticated with a hashed anti-tracking count (HATC). An HATC canbe generated with a hash function operating on at least the LTK and achanged (e.g., incremented) A-T count value. In some embodiments, anonce and another count value (i.e., not an A-T count value) can beincluded in the hashing operation. If authentication of the HATC fails,communications can end, preventing replay attacks from generating aresponse. If the HATC is authenticated, the two devices can re-establishthe encrypted connection without having to exchange protected dataagain. In some embodiments, enhanced privacy can be provided in aBluetooth (BT), network (e.g., piconet), including BT Low Energy (BLE)networks.

In some embodiments, enhanced privacy can be provided in aneighbor-aware-network (NAN), such as a WiFi Aware network.

In some embodiments, a received HATC can be authenticated againstmultiple local HATCs, where the local HATCs are generated with differentchanged A-T count values. In some embodiments, one local HATC can begenerated with an A-T count incremented by a first amount (e.g., +1),while another HATC can be generated with an A-T count incremented by asecond amount (e.g., +2).

In some embodiments, once an encrypted connection has been established,an A-T count can be updated (e.g., incremented). This can includeupdating the A-T count based on which local HATC authenticated areceived HATC.

FIG. 1 is a flow diagram of a method 100 according to an embodiment. Amethod 100 can be executed by a “responding” device that “bonds” with a“requesting” device. A method 100 can include establishing an encryptedconnection with a peer 102. Such an action can include executing aconnection procedure according to a predetermined protocol. Such aprotocol can include a publicly known standard, or can include aproprietary standard. Such an action can include establishing securityvalues, including long term keys (LTKs) and an A-T count. Establishingsuch values can include an exchange of values and/or the generation ofsuch values based on agreed upon methods. An encrypted connection canfollow any suitable encryption method, including the use of public keys,private keys and combinations thereof. LTKs can be keys used forencryption and decryption of communications. An A-T count can be a valueessentially shared between the two devices. An A-T count can be updatedeach time encrypted communications are re-established between the twodevices.

A method 100 can include securely storing LTKs and A-T count values.Such an action can include storing such values in a secure nonvolatilememory. The encrypted connection can end 108. Such an action can includeeither device ending the connection, or some condition causing theconnection to be ended.

A method 100 can determine if a communication has been received with apeer ID 110. In some embodiments, such an action can include determiningif a received packet includes a field identifying it as beingtransmitted from a known peer.

In some embodiments, this can include “resolving” and address oridentification value with an identity key for the peer device. Such aresolving operation can include performing a hash operation on areceived value with identity keys, and comparing the resulting hashvalues with a received hash value. If a communication is received thatincludes a peer identification (ID) value 110, a method 100 candetermine if the communication includes a hashed anti-tracking count(HATC) 112. Such an action can include determining the type ofcommunication received. In some embodiment, a peer device can send atransmission that includes one or multiple HATCs (e.g., anadvertisement). If a communication that appears from a peer does notinclude an HATC (N from 112), an HATC can be requested from the peerdevice 114. Such an action can include transmitting a packet thatidentifies the peer (e.g., an address) and includes a field indicatingthe request for an HATC. If an HATC is not received in response to arequest (N from 116), a method 100 can attempt another connection method118, or in some embodiments, may end communications.

If a communication received from the peer includes an HATC (Y from 112)or a requested HATC has been received (Y from 116), a method 100 canauthenticate the HATC with an A-T count the varies as expected 120. Insome embodiments, such an action can include generating a hash valuewith a hash function that operates on a changed A-T count value. Achanged A-T count value can be the stored A-T count value changed in apredetermined manner (e.g., incremented and/or decremented). Such anauthentication operation can include comparing a received HATC tomultiple locally generated HATCs.

If authentication succeeds (Y from 120), a method 100 can establish anencrypted connection without the need to re-establish encryption keys124. Such an action can enable relative rapid reconnection with bondedpeers. A stored A-T count can be updated 126. Such an action can includechanging a stored A-T count in a predetermined manner (e.g.,incrementing, decrementing).

If authentication fails (N from 120), a method 100 can make no response122 (e.g., end communications). In this way, a method 100 can provideenhanced privacy, as a device cannot be detected and/or tracked byeliciting a response with a communication using a previous peer ID value(e.g., a replay attack). This is in contrast to conventional approachesin which a device can respond to communications that include an ID valuecorresponding to a previously bonded peer.

FIG. 1B is a diagram showing enhanced privacy values 130 of a wirelessdevice according to an embodiment. Such enhanced privacy values 130 canbe stored in a secure memory of a device. Enhanced privacy values 130can include a number of peer enhanced entries 132-0 to -n. Each peerentry (132-0 to -n) can correspond to a different peer device. Peerentries (132-0 to -n) can include a long term key (LTK_x), an A-T count(A-T COUNT_x), a nonce value (NONCE_x) and a peer ID key (PEER_x IDKEY), where x corresponds to an entry.

FIG. 1B also shows an HATC 134 according to an embodiment. An HATC canbe generated for a peer device using entry values (132-0 to -n) for thepeer device. HATC can be generated with a hash function operating on astring value, a changed A-T count value (A-T count+i), a long term key,a nonce value corresponding to the peer, and the A-T count valuecorresponding to the peer.

In this way, a device can securely store peer values to authenticatecommunications with an anti-tracking value that varies with eachsubsequent connection. This can enable replay attacks to be ignored,thus providing enhanced privacy.

FIG. 2 is a flow diagram of a method 200 according to an embodiment. Amethod 200 can be executed by a requesting device that issues a requestto a responding device to re-establish a connection without having toexchange security information. A method 200 can include actions likethose described for FIG. 1A, including establishing an encryptedconnection with a peer 202, establishing LTKs and A-T counts 204, andsecurely storing the LTKs and A-T counts 206. The encrypted connectioncan end 208. Such an action can include any of those described hereinand equivalents.

A method 200 can determine whether or not to generate a message thatincludes an HATC 236. How such an action occurs can depend upon theprotocol used and/or mode of operation. In some embodiments, a messagewith an HATC can be periodically generated in a communication (e.g.,advertisement). In some embodiments, a message with an HATC can begenerated in response to a request for an HATC.

A method 200 can transmit a message with an HATC 238. Such an action caninclude generating an HATC by hashing multiple values, one of which is astored A-T count altered in a predetermined manner (e.g., incremented ordecremented).

A method 200 can establish an encrypted connection without the need tore-establish encryption keys 224. As noted, such an action can enablerelative rapid reconnection with bonded peers. A stored A-T count can beupdated 226′. Such an action can include changing a stored A-T count ina predetermined manner (e.g., incrementing, decrementing).

While embodiments, can operate with any suitable wireless protocol, someembodiments can include devices compatible with one or more Bluetooth(BT) standards (which are understood to include Bluetooth Low Energy,BLE). FIG. 3 shows a system 300 (and corresponding method) with BTdevices according to an embodiment. A system 300 can include a BTcentral device 342 and a BT peripheral device 338. Central andperipheral devices 342/338 can be peer BT devices that can communicatedirectly with one another according to one or more BT standards.

Central and peripheral devices 342/338 can initially perform a pairingoperation 344 that includes establishing an initial encrypted connectionto enable the transfer of secure data (e.g., keys). A pairing operation344 can take any suitable form, and in the embodiment of FIG. 3 caninclude a peripheral device 338 requesting security features, includingif a central device supports enhanced privacy (ep) 344-0. Enhancedprivacy can include any of the techniques described herein orequivalents, detecting replay attacks and not respond to such an attackby using a changing A-T count. In response to the request 344-0, aresponding device 342 can generate response indicating that is supportsep 344-1. Central and peripheral devices 342/338 can establish orexchange temporary encryption keys 344-2. Using such the temporaryencryption keys, central/responding 342/338 can establish an encryptedconnection 344-3.

With an encrypted connection established, central/peripheral devices342/338 can execute a bonding operation 346. Such an operation caninclude exchanging (or establishing) long term connection values, andsecurely storing such values 346-0. Long term connection values caninclude but are not limited to: long term media access control (MAC)addresses, identity resolving keys (IRKs), LTKs and a shared A-T countvalue. With a bonded connection, central/peripheral devices 342/338 canexchange data 346-2.

An encrypted connection between the devices can be ended 308. Such anaction can include, but is not limited to, either device ending theconnection, or external circumstances resulting in the ending of theconnection. A central device 342 can receive an advertisement 310 thatappears to be from a peripheral device. In some embodiments, this caninclude receiving a communication with resolvable private address (RPA),and resolving such an address with a stored IRK corresponding to a peer.A received advertisement can be checked for an HATC 312. In someembodiments, this can include determining a type of advertisement, andexamining predetermined data fields. Said in another way, someadvertisements may include one or more HATCs, while others may not.

If a detected advertisement does not have an HATC, a method 300 caninclude requesting an HATC 314. Such an action can include generating aresponse addressed to the peripheral device. In some embodiments, suchan address can include an RPA for central device 342. A peripheraldevice 338 can confirm an identity of an HATC request from centraldevice 350. In some embodiments, this can include resolving an RPA witha stored IDK for the central device 342. If the HATC request is notverified (N from 350), a method 300 can stop 352′, or in someembodiments connection can be sought with an alternate protocol (e.g.,bonding). If the HATC request is verified (Y from 350), a peripheraldevice can compute an

HATC as described herein (i.e., with an incremented A-T count), and thentransmit a message to the central device that includes the computed HATC356. If a central device never receives an HATC after a request (N from316), a central device may stop communications 352 with no furtherresponses. If a central device receives an HATC in an advertisement (Yfrom 312) and/or receives a requested HATC (Y from 316), the receivedHATC can be authenticated with changed A-T counts that are incrementedby one and incremented by two 320. In some embodiments, such an actioncan include generating two HATCs according to the accepted definition,and determining if the received HATC matches either. If a received HATCfails authentication (Invalid from 320), a central device may stopcommunications 352 with no further responses. Such an action can defeata replay attack without revealing the presence of the central device342. If a received HATC is authenticated (Valid from 320), an encryptedcommunication can be re-established with the peripheral device usingLTKs previously received and stored in a bonding operation 324. If areceived HATC was authenticated using an A-T count incremented by two (Yfrom 358), a central device's A-T count can be incremented 326. If areceived HATC was not authenticated using an A-T count incremented bytwo (N from 358), or the A-T count was incremented due to a verificationcorresponding to A-T+2 (326), a central device's A-T count can beincremented 326′. Such an action can account A-T counts that may varydue to connections being lost.

After an encrypted communication is received from the central deviceover the re-established connection 360, the peripheral device 338 canincrement it's A-T count 362.

In this way, BT systems can include a hashed anti-tracking count thatcan be generated with an anti-tracking count that can be incrementedwith each connection event between bonded pairs.

FIGS. 4A and 4B are diagrams showing how another wireless system canbenefit from enhanced privacy as described herein. FIGS. 4A and 4B showa system 400 (and corresponding method) operating a neighbor awarenetwork (NAN) with enhanced privacy. In some embodiments the NAN systemcan be compatible with a WiFi Aware standard. A publisher device 442 caninclude a service publisher 442-0 and a NAN publisher 442-1. Asubscriber device 438 can include a service subscriber 438-0 and NANsubscriber 438-1.

FIG. 4A shows a pairing operation according to an embodiment. A pairingoperation can include a service subscriber 438-0 subscribing to aservice 463-0. In response, NAN subscriber 438-1 can generate asubscriber message that includes an NIR tag (NIR_s) 463-1. A servicepublisher 440-0 can publishing a service 461-0. A NAN publisher cangenerate a publication method that includes a NIR tag (NIR_p) 461-1. Asubscriber device 438 can resolve NIR_p to discover the service instance463-2 for the publisher device 442.

After the service instance is discovered 464, a subscriber device 438can start a pairing setup operation 464. Such an action can includeout-of-band (OOB) bootstrapping 465. This can include a passwordconfirmation in publisher device 467-0, and a password confirmation insubscriber device 467-1. A subscriber device 438 can send a firstpre-association security negotiation message (PASN(M1)) 475. Inresponse, a publisher device 442 can return a second PASN message(PASN(M2)) 466. A subscriber device 438 can end the security negotiationwith a third PASN message (PASN(M3)) 468.

PASN messaging can result in the generation of a pairwise master key(PMK), temporary key (TK) and key distribution key (KDK). Unlikeconventional operations, PASN messaging can also establish the A-T countfor the subscriber-publisher pair 438/442.

After a pairing setup has ended 474, in some embodimentspublisher/subscriber devices 442/438 can have follow-up communicationsthat can exchange, establish or confirm security values (e.g., A-Tcount). In the embodiment of FIG. 4A, follow up protected managementframes (PMFs) 476/478 can result in establishing security values.

A data path can then be setup 424 to enable communications between thepublisher device 442 and subscriber device 438.

FIG. 4B shows a system 400 (and corresponding method) for a pairingverification operation according to an embodiment. Such an operation cantake place after devices have undergone a pairing setup operation likethat shown in FIG. 4A. A subscriber device 438 can include a servicesubscriber 438-0 subscribing to a service 482-0, and issuing an initialsubscribing message 482-1. Such a message can include a NAN tag (NIR_s).A publisher device 442 can include a service publisher 442-0 publishinga service 480-0. In response to subscription message 482-1, publisherdevice 442 can look up NIK values in an NIK table to try to identifyNIR_s (i.e., authenticate the subscriber device 438), with a hashfunction as follows:

NIR_s=Truncate-64(HMAC-SHA-256(NIK_s, “NIR”, NMI_s∥Nonce_s∥counter_s)),

where NIK_s is one of the NIK values; “NIR” is a string value (which canbe NIR), NMI_s is a NAN management interface address corresponding toNIK_s, Nonce_s is a nonce value corresponding to NIK_s, and counter_s isa counter value (not an A-T count) for NIK_s. In some embodiments a hashfunction can be the HMAC-SHA-256 hash function. Truncate-64 can be a64-bit truncation of the value.

If a publisher device 442 resolves the received NIR_s value, it canretrieve and A-T count for the subscriber device 438 (which in someembodiments can be stored with the NIK_s value). A publisher device 442can publish a message 480-1 with an enhanced privacy identity resolvingvalue with a hash function as follows:

eNIR_p=Truncate-64(HMAC-SHA-256(NIK_p, “NIR”, NMI_p∥Nonce_p∥counter_p IIA-T count_sp+1)),

where NIK_p is for the publisher device 442; “NIR” is a string value,NMI_p is a NAN management interface address corresponding to NIK_p,Nonce_p is a nonce value corresponding to NIK_p, and counter_p is acounter value for NIK_p, and A-T count_sp can be an A-T count for thesubscriber-publisher connections. An eNIR value is understood to be oneversion of an HATC.

A subscriber device 438 can receive the publication with eNIR_p, and seeif such a value can be resolved against stored NIKs and theircorresponding A-T counts 484. In some embodiments, this can includedetermining if a received eNIR_p satisfies either:

eNIR_p=Truncate-64(HMAC-SHA-256(NIK_p, “NIR”,NMI_p∥Nonce_p∥counter_p∥A-T count_sp+1)) or

eNIR_p=Truncate-64(HMAC-SHA-256(NIK_p, “NIR”,NMI_p∥Nonce_p∥counter_p∥A-T count_sp+2)),

where NIK_p and A-T count_sp are corresponding values that yield amatch.

If a received eNIR_p cannot be resolved (N from 484) (e.g., neither ofthe above condition is satisfied), the subscriber device 438 cansilently abort the connection to prevent tracking with follow-oncommunications. If a received eNIR_p can be resolved (Y from 484) (e.g.,one of the above conditions is satisfied), the paired peer can bediscovered 488 and the devices can start an enhanced privacy pairverification operation 490.

In an enhanced privacy pair verification operation, a subscriber device438 can send a PASN(M1) 492 to the service publishing device 442. Thepublishing device 442 can respond with a PASN M2 494 to the subscriberdevice 438. A subscriber device 438 can check a received PASN M2 toverify the publisher device 442 possesses a shared key establishedduring a previous pairing setup process. If PASN M2 is validated, asubscriber device 438 can increment its A-T count 498 if it wasdetermined (in 484) that the eNIR_p was generated with an A-T count+2value (Y from 496). A subscriber device 438 can generate a TK and KDK,and return a PASN M3 499.

A publisher device 442 can check a received PASN M3 to verify thesubscriber device 438 possesses a shared key established during aprevious pairing setup process. If PASN M3 is validated, the publisherdevice can generate a TK and KDK 495. In addition, it can increment itsstored A-T count 493. A pair verification operation can be considered tobe ended 491.

Publisher device 442 and subscriber device 438 can exchange encrypteddata. In FIG. 4B such an action can include a subscriber device 438sending a PMF 476, and publisher device 442 sending a PMF 487. Afterreceiving some encrypted data from the publisher device 442 correctly,the subscriber device 438 can increment its A-T count value 498. Theincremented A-T count can replace that stored in a NIK table, which canbe stored in a non-volatile memory.

It is noted that if the connection is broken or if for any reason (suchas sudden crash) a subscriber device 438 may not be able to incrementits A-T count (498). This can result in a publisher device's A-T countbeing larger than that of the subscriber device. However, through action484, such a discrepancy can be accounted for in resolving eNIR_p and acount value can be corrected with incrementing step 498. A data path canbe set up 424. In this way, NAN systems can include an enhanced privacyNIR that can include a count value that can be used to defeat replayattacks aimed as eliciting a response.

FIG. 5 is a block diagram of a device 538 according to an embodiment.Device 538 can be a central/peripheral or a publisher/subscriber deviceas described for embodiments herein and equivalents. A device 538 caninclude a controller 552, radio control circuits 578, radio circuits 580and input/output (10) circuits 582. A controller 552 can include aprocessor section 554 and nonvolatile memory 556. A processor section554 can include circuits for executing various functions descriedherein, including but are not limited to: one or more processors withcorresponding memory, custom logic, programmable logic, or combinationsthereof. In some embodiments, a processor section 544 can executeinstructions 566 stored in nonvolatile memory 556.

In the embodiment shown, a processor section 554 can provide one or morehash functions 558, one or more nonce value generators 560, and acounter circuit 562. Hash function(s) 558 can be hash functionsdetermined by a predetermined standard and/or communication/negotiationbetween peer devices. Hash function(s) 558 can be used to generate ahash with varying A-T count values as described herein and equivalents(e.g., A-T count+1/+2). Such a hash can be included in a message tore-establish communications with a previously bonded/paired device,using previously exchanged/established security values (e.g., LTKs). Insome embodiments, to generate the hash, a hash function 558 can operateon a number of values, including but not limited to: a key and changedA-T count value, as described herein and equivalents. Nonce valuegenerator(s) 560 can generate nonce values for use by device 538,including for use in generating hash values and described herein. Acounter circuit 562 can update an A-T count value that varies each timea connection is made or reestablished with a peer device. An A-T countupdated by counter circuits 562 can be stored in nonvolatile manner. AnA-T count can be used in the generation of hash values and to defeatreplay attacks as described herein.

A processor section 554 can also execute communication controloperations 564. Communication control operations 564 can include, butare not limited to, framing/de-framing circuits 564-0 and an HATCevaluation function 564-1. Framing/de-framing circuits 564-0 can composedata frames for transmission to peer devices, including generatingfields that include an ID value formed by the concatenation of hash withother values (e.g., any of a count, a nonce or a string). HATCevaluation function 564-1 can include circuits configured to compare areceived HATC value, with generated HATC values. In some embodiments,this can include comparing a received HATC with a first HATC generatedwith an A-T count +1, and with a second HATC generated with an A-T count+2.

Nonvolatile memory 556 can include instructions 566 and one or moresecure storage regions 568. Instructions 566 can include instructionsexecutable by processor section 554 to perform any or all operationsdescribed herein. In some embodiments, all or a portion of instructions566 can be firmware and/or stored in secure nonvolatile memory. Securestorage regions 568 can store a local ID key for the device 538 as wellas ID keys 572 and A-T counts 574 for any peers with whichsecurity/privacy data has been exchanged.

Radio control circuits 578 can control how peer communications aretransmitted. Radio control circuits 578 can operate according to anysuitable wireless standard or protocol that can generate packets thatinclude HATC values as described herein or equivalents. IO circuits 582can enable control of device 538 from sources external to the device538. IO circuits 582 can enable communication with the device accordingto any suitable fashion. In some embodiments, 10 circuits 538 caninclude serial communication circuits, including but not limited to:serial digital interface (SDI), universal serial bus (USB), universalasynchronous receiver transmitter (UART), I²C, or I²S.

A device 538 can be connected to an antenna system 584. An antennasystem 584 can include one or more antennas for transmitting andreceiving wireless signals, as well as switches for enabling anddisabling connections to such antennas.

FIG. 6A shows a BT device 638 according to an embodiment. A BT device638 can be a central or peripheral device as described herein. BT device638 can include a controller 652, BT control circuit 678, BT radiofrequency (RF) circuit 680, and 10 circuits 682 in communication withone another with a bus 688. A controller 652 can include a processorsubsystem 654 and a memory subsystem 656.

A processor subsystem 654 can include one or more processors configuredto execute instructions for various operations of the device. Suchoperations can include, but are not limited to: pairing 644, enhancedprivacy bonding 646, HATC generation 646-1, HATC evaluation 664-1, oneor more hash functions 658, a counter 662, and a nonce generator 660.Pairing 644 can include executing pairing operations according to one ormore BT standards. Bonding 646 can include bonding according to one ormore BT standards, but further include establishing an A-T count valuefor each peer. An A-T count value can be incremented when connectionsare re-established between BT peers, as described herein.

HATC generation 646-1 can generate an HATC value for BT communications,as described herein or an equivalent. In the embodiment shown, an HATCvalue can be generated by

HATC=Hash(“HTAC”∥A-T Count+i∥LTK∥nonce_q∥count_q)

where Hash is a hash function; “HTAC” is a string value; A-T Count+i isan A-T count incremented by one or two; nonce_q is a nonce value of adevice receiving the HATO; and count_q is a count value (which is not anA-T count).

HATC evaluation 664-1 can include a device 638 generating two local HATCvalues, one with an A-T count incremented by one (HATC(local1)) and onewith an HATC value incremented by two (HATC(local2)). The two localvalues can be compared to a received HATC value (HATC(peer)). If thereis a match, the peer device can be authenticated as a previously bondeddevice. Further, from a match it can be determined whether the A-T countof the peer device matches that of device 638 (HATC(peer)=HATCH(local1),or if the A-T count of the peer device is currently one less than thatof the device 638 (HATC(peer)=HATC(local2). A hash function 658 caninclude one or more BT hash functions, including an address hashfunction (ah). A counter 662 can increment an A-T count when a device638 establishes a connection with a peer. Nonce generator 660 cangenerate nonce values for use with the generation of HATCs.

Memory subsystem 656 can include any suitable memory circuit types,including nonvolatile and/or volatile memory. A memory subsystem 656 canstore any suitable data for the operation of the device 638, includinginstructions executable by processor subsystem 654 to provide thevarious operations described. A memory subsystem 656 can also include asecure nonvolatile memory 668 which can store various values related tosecurity and privacy. In the embodiment shown, a secure nonvolatilememory 668 can include an IRK table 669. An IRK table 669 can includelocal values for the device 638, including a local IRK 670 and a localLTK 686-0. In addition, there can be entries for each peer, including anIRK 672-i, LTK 673-i and A-T count 674-l (where i corresponds to aparticular entry). BT control circuits 678 can enable communicationsaccording to one or more

BT standards, including BLE. BT control circuits 678 can format andpacketize data for transmission by BT circuits, as well as de-packetizereceived packets. This can include any of: generating advertisingpackets with HATCs for each bonded peer, or generating a response packetfor a peer that includes an HATC for the peer.

BT RF circuit 680 can include radio circuits compatible with one or moreBT standards, including receiving and transmitting packets according toa BT standard. IO circuits 682 can enable communication with betweendevice 638 and a peer BT device.

A device 638 can operate in conjunction with an antenna system 982,which can be compatible with one or more BT standards.

FIG. 6B is a diagram showing an enhanced privacy packet 690 that can betransmitted according to an embodiment. A packet 690 can include apreamble, access address, protocol data unit (PDU), and cyclicredundancy check (CRC). A PDU can include a header portion and payload.A payload can include one or more HATCs 630, as described herein, or anequivalent.

In this way, BT systems can be provided with enhanced privacycapabilities to detect replay attacks with the inclusion of an HATC in amessage to a peer.

FIG. 7A show a device 738 according to another embodiment. A device 738can be compatible with a WiFi Aware standard. A device 738 can be apublisher device or a subscriber device as described herein. Device 738can include a controller 752, IEEE 802.11 media access control layer(MAC) circuits 778A, IEEE 802.11 physical layer (PHY) circuits 778B,IEEE 802.11 RF circuits 780, and IO circuits 782 connected to oneanother via a backplane 788. A controller 752 can include a memorysubsystem 756 and processor subsystem 754, which can include anysuitable circuits as described herein or equivalents. In the embodimentshown, a device 838 can establish protected data paths and/or data linkswith other peer devices that can include enhanced privacy.

Memory subsystem 756 can include any suitable memory circuit types,including nonvolatile and/or volatile memory. A memory subsystem 756 canstore any suitable data for the operation of the device 738, includinginstructions executable by processor subsystem 754 to provide thevarious operations described. A memory subsystem 756 can include asecure nonvolatile memory 768 which can store various values related tosecurity and privacy. Such values can include, but are not limited to: alocal NIK 770, one or more peer NIKs 772, and one or more peer counts776.

Processor subsystem 754 can include one or more processors configured toexecute instructions for various operations of the device. A NANdiscovery engine 792 can detect NAN devices/services according to apredetermined standard, including a WiFi Aware standard. A NAN dataengine 794 can generate communications for setting up data paths/linkswith other peer devices. In the embodiment shown, a NAN data engine 794can execute eNIR generation operations 746-1 and eNIR evaluationoperations 716. eNIR generation operations 746-1 can generate an eNIRfor WiFi Aware data paths/links, as described herein or an equivalent.An eNIR evaluation operation 716 can resolve a received peer eNIR andcan compare it to two local eNIRs, one generated with A-T Count+1, theother generate with A-T Count+2. From such an operation, a device 738can determine if a peer A-T count is equal to or less than the storedA-T count, as descried herein.

A hash function 758 can include one or more hash functions, and in someembodiments, can include hash functions indicated by the WiFi Awarestandard (e.g., HMAC-SHA-256). A counter 762 can increment an A-T countwhen a device 738 re-establishes a connection with a peer. Noncegenerator 760 can generate nonce values for use with eNIRs.

MAC circuits 778A can be compatible with one or more IEEE 802.11wireless standards, and can include NAN MAC layer 924A which can includeMAC functionality that can be particular to one or more NAN protocolsbeing used. PHY circuits 778 can be compatible with one or more IEEE802.11 wireless standards, including but not limited to IEEE 802.11n and802.11ac. RF circuit 780 can include radio circuits compatible with oneor more IEEE 802.11 wireless standards, and transmit and receive on anyof 2.5 GHz, 5 GHz or 6 GHz bands. IO circuits 782 can enablecommunication with device 738 according to any of the embodiments hereinor equivalents.

A device 738 can be connected to an antenna system 784 that can receiveand transmit signals compatible with one or more IEEE 802.11 wirelessstandards. FIG. 7B is a diagram showing a packet 790 that can betransmitted and received by a device 738 according to an embodiment.Packet 790 can be compatible with an IEEE wireless standard. In theembodiment shown, packet 790 can include a frame control field, durationfield, address fields, a frame body, and a frame check sequence. A framebody can include one or more HATCs, as described herein.

In this way a NAN device can include a NIR(ep) which can identify a peerand defeat replay attacks aimed at reusing a NIR in a replay attack.

While embodiments can include devices and systems with variousinterconnected components, embodiments can also include unitary deviceswhich can be provide enhanced privacy through the generation and use ofHATCs as described herein. In some embodiments, such unitary devices canbe advantageously compact single integrated circuits (i.e., chips). FIG.8 shows a packaged single chip device 838 according to an embodiment. Asingle chip device 838 can take the form of those shown in FIGS. 5, 6Aor 7A, as well as a combination device that includes both BT and NANtype circuits.

However, it is understood that a device according to embodiments caninclude any other suitable integrated circuit packaging type, as well asdirect bonding of a device chip onto a circuit board or substrate.

FIG. 9 is a block diagram of a system 996 according to anotherembodiment. A system 996 can include, or a peer device as describedherein. A system 996 can include a processor system 954, a memory system956, wireless circuits 996, positioning circuits 997, cellular circuits995, audio control circuits 993, display control circuits 991, cameracontrol circuits 989, and near field communication (NFC) circuits 987.

A processor system 954 can take the form of any of those describedherein, or equivalents, and can provide various functions according toinstructions 966 stored in memory system 956. Instructions 966 caninclude, but are not limited to, an operating system and one or moreapplications that employ preexisting functions available through theoperating system. Functions provided by a processing system 954 caninclude, but not limited to, a hash function 958, nonce generator 960,counter 962, HATC generator 946-1, and HATC compare 964-1. Suchfunctions can take the form of any of those described herein, orequivalents.

A memory system 934 can include nonvolatile “flash” memory 985 andvolatile dynamic random access memory (DRAM) 983. Flash memory 985 caninclude a secure storage region 968 that can store various values forexecuting enhanced privacy as described herein or equivalents. Storedvalues can include, but are not limited to, a local ID key 970, peer IDkeys 972, encryption keys 975 and peer A-T counts 976. Such values cantake the form of any of those described herein or equivalents.

Wireless circuits 996 can include BT circuits 996 a and WLAN circuits996 b. BT circuits 996 a can be compatible with one or more BTstandards, including BLE. WLAN circuits 996 b can be compatible with oneor more IEEE 80.211 wireless standards. In some embodiments, wirelesscircuits 996 can be part of a combination integrated circuit device.Wireless circuits 996 can be connected to an antenna system 984.Cellular circuits 995 can provide communication functions according toone or more cellular standards and can be connected to a cellularantenna system 983.

Location circuits 997 can determine a location of a system 996, and insome embodiments can include GPS circuits. NFC circuits 987 can provideNFC capabilities for the system 996. Audio control circuits 993 canprovide audio functions for the system 996. Display control circuit 991can control a display 979 of the system 996, which an also serve as auser input (e.g., a touchscreen). A camera control circuit 989 cancontrol a camera system 977.

In some embodiments, a processor system 954, memory system 956, andwireless circuits 996 can be formed by a system-on-chip (SoC) typedevice. In operation, a system 996 can establish encrypted connectionswith peer devices according to any of its wireless capabilities. Oversuch a connection, ID keys, encryption keys, and A-T counts can beestablished. From such values, as well as other additional values (e.g.,nonce, non-A-T counter values), HATC values can be generated foridentifying peer devices with which security has been established (e.g.,bonded devices). When a communication is received that appears to befrom a peer, an HATC value can be authenticated to defeat any possiblereplay attack, as described herein and equivalents. That is, failure ofHATC authentication can result in any further communications from thesource being ignored, preventing a system 996 from being tracked with areplay attack.

In this way, handheld electronic devices can operate with improvedprivacy that can preventing tracking by use of replay attacks.

While system embodiments can take any suitable form, in someembodiments, a system can be a portable electronic device, such as ahandheld device, or the like. FIG. 10 shows such a system 1096 accordingto an embodiment. A system 1096 can be one implementation of that shownin FIG. 9 .

FIG. 11 shows a system 1195 according to another embodiment. A system1195 can include various peer devices 1196-0 to -5. Peer devices (1196-0to -5) can provide enhanced privacy as described herein. Peer devices(1196-0 to -5) can execute methods as described for FIGS. 1A to 4 ,include devices as shown in FIGS. 5 to 8 , or include a system as shownin FIG. 9 , or equivalents to any such methods, devices or systems.

In the embodiment shown, peer devices (1196-0 to -5) can beInternet-of-things (loT) type devices, such as instrumentation devices1050-0, medical devices 1196-1/2, lighting devices 1196-3, or, securitydevices 1196-4/5, as but a few of many possible examples. Peer devices(1196-0 to -5) can provide for rapid connection with previouslyconnected (e.g., bonded) devices, while at the same time ignoring replayattacks that may replay a device identity value. In this way, networksof IoT devices can have enhanced security.

Embodiments can include a method that establishes a wireless encryptedconnection; establishes a LTK and an A-T count value for the peerdevice; and stores the LTK and A-T count value in a nonvolatile memorycircuit. Communications can be received that include an identity valuecorresponding to the peer device and a peer HATC. At least one localHATC can be generated by executing a predetermined hash function on atleast the LTK and a changed A-T count value. A changed A-T count valuecan be one that varies from the stored A-T count value by apredetermined amount. The received peer HATC can be authenticated withthe at least one local HATC. In response to the peer HATC beingauthenticated, communications can occur with the peer device. Inresponse to the peer HATC not being authenticated, the peer device canbe ignored (not responded to).

Embodiments can include a device having a nonvolatile memory configuredto store at least an LTK, an anti-tracking (A-T) count, and a noncevalue. A device can also include a controller. A controller can beconfigured to establish wireless encrypted connections, receive acommunication from a peer device that include an

HATC, and generate at least one local HATC by hashing at least the LTK,the peer nonce, and a changed A-T count value. A controller can furtherauthenticate the received peer HATC with the at least one local HATC. Ifthe peer HATC is not authenticated, communications are not made with thepeer device. If the peer HATC is authenticated, communications can bemade with the peer device.

Embodiments can include a system with a first wireless device thatincludes circuits configured to store at least a LTK, an A-T count, anda peer nonce value for a peer device. Such circuits can also establish awireless encrypted connection with at least the LTK, receive acommunication from a peer device that includes an HATC, generate atleast one local HATC by hashing at least the LTK and a changed

A-T count value. The circuits can also authenticate the received peerHATC with the at least one local HATC. If the peer HATC is notauthenticated, the first wireless device will not communicate with thepeer device. If the peer HATC is authenticated, the first wireless cancommunicate with the peer device.

Methods, devices and systems according to embodiments can includegenerating a first local HATC with a first changed A-T count value thatvaries from the stored A-T count value by a first amount, and generatinga second local HATC with a second changed A-T count value that variesfrom the stored A-T count value by a second amount. The peer HATC can beauthenticated with the first and second local HATCs. In someembodiments, a first changed A-T count can be incremented by one, and asecond changed A-T count can be incremented by two.

Methods, devices and systems according to embodiments can includeestablishing and/or re-establishing the encrypted connection compatiblewith at least one wireless standard selected from the group of: BT andWiFi Aware.

Methods, devices and systems according to embodiments can include adevice requesting a peer HATC from what appears to be a peer device.

Methods, devices and systems according to embodiments can include, inresponse to the peer HATC being authenticated, re-establishing awireless encrypted connection with the peer using at least the LTK. Inresponse to receiving a communication from the peer over there-established encrypted connection, the stored A-T count can bechanged. In some embodiments, changing the stored A-T count can includeincrementing the stored A-T count.

Methods, devices and systems according to embodiments can include adevice with a nonvolatile memory and controller formed with a sameintegrated circuit substrate.

Methods, devices and systems can include a device with counter circuitsconfigured to update the A-T count in the nonvolatile memory, andarithmetic logic circuits configured to execute the hash function.

Methods, devices and systems can include a device with radio circuitsconfigured to receive and transmit packets from the peer device that arecompatible with at least one wireless standard. A wireless standard caninclude either of a BT standard or a WiFi Aware standard.

Methods, devices and systems can include an HATC generated with a hashfunction executed on a string value, a changed A-T count, a LTK, anonce, and an A-T count.

Methods, devices and systems can include a peer wireless device havingpeer circuits configured to store the LTK, a peer A-T count, and a peernonce. A peer wireless device can generate a peer HATC by hashing atleast the LTK, the peer nonce, the A-T count value, a nonce value, and achanged A-T count value that varies from the stored A-T count value by apredetermined amount. A peer wireless device can transmit a packet thatincludes the peer HATC. The peer device can also include a peer antennasystem configured to transmit the request as a packet according to theat least one wireless standard.

Methods, devices and systems can include a first wireless device withcircuits configured to, in response to a peer HATC being authenticated,re-establish a wireless encrypted connection with the peer with at leastthe LTK, and, in response to receiving a communication from the peerover the re-established encrypted connection, changing the stored A-Tcount. The peer wireless device can be configured to, in response toreceiving a communication from the first device over the re-establishedencrypted connection, change its stored peer count value.

It should be appreciated that reference throughout this specification to“one embodiment” or “an embodiment” means that a particular feature,structure or characteristic described in connection with the embodimentis included in at least one embodiment of the present invention.Therefore, it is emphasized and should be appreciated that two or morereferences to “an embodiment” or “one embodiment” or “an alternativeembodiment” in various portions of this specification are notnecessarily all referring to the same embodiment. Furthermore, theparticular features, structures or characteristics may be combined assuitable in one or more embodiments of the invention.

Similarly, it should be appreciated that in the foregoing description ofexemplary embodiments of the invention, various features of theinvention are sometimes grouped together in a single embodiment, figure,or description thereof for the purpose of streamlining the disclosureaiding in the understanding of one or more of the various inventiveaspects. This method of disclosure, however, is not to be interpreted asreflecting an intention that the claims require more features than areexpressly recited in each claim. Rather, inventive aspects lie in lessthan all features of a single foregoing disclosed embodiment. Thus, theclaims following the detailed description are hereby expresslyincorporated into this detailed description, with each claim standing onits own as a separate embodiment of this invention.

While this invention has been described with reference to illustrativeembodiments, this description is not intended to be construed in alimiting sense. Various modifications and combinations of theillustrative embodiments, as well as other embodiments of the invention,will be apparent to persons skilled in the art upon reference to thedescription. It is therefore intended that the appended claims encompassany such modifications or embodiments.

What is claimed is:
 1. A method, comprising: establishing a wirelessencrypted connection; establishing a long term encryption key (LTK) andan anti-tracking (A-T) count value for a peer device; storing the LTKand A-T count value in a nonvolatile memory circuit; receiving acommunication that includes an identity value corresponding to the peerdevice and includes a peer hashed anti-tracking count (HATC); generatingat least one local HATC by executing a predetermined hash function on atleast the LTK and a changed A-T count value that varies from the storedA-T count value by a predetermined amount; authenticating the receivedpeer HATC with the at least one local HATC; in response to the peer HATCbeing authenticated, communicating with the peer device; and in responseto the peer HATC not being authenticated, not communicating with thepeer device.
 2. The method of claim 1, wherein: generating the at leastone local HATC includes generating a first local HATC with a firstchanged A-T count value that varies from the stored A-T count value by afirst amount, and generating a second local HATC with a second changedA-T count value that varies from the stored A-T count value by a secondamount different than the first amount; and authenticating the receivedpeer HATC with the first local HATC or the second local HATC.
 3. Themethod of claim 2, wherein: the first changed A-T count value is thestored A-T count value incremented by one; and the second changed A-Tcount value is the stored A-T count value incremented by two.
 4. Themethod of claim 1, wherein establishing the encrypted connectionincludes establishing a connection compatible with at least oneBluetooth (BT) standard including Bluetooth Low Energy.
 5. The method ofclaim 1, wherein establishing the encrypted connection includesestablishing a connection compatible with at least one WiFi Awarestandard.
 6. The method of claim 1, wherein receiving the communicationthat includes the identity value and the peer HATC includes requestingthe HATC from the peer.
 7. The method of claim 1, further including: inresponse to the peer HATC being authenticated, re-establishing awireless encrypted connection with the peer with at least the LTK, andin response to receiving a communication from the peer over there-established encrypted connection, changing the stored A-T count. 8.The method of claim 7, wherein changing the stored A-T count includesincrementing the stored A-T count.
 9. A device, comprising: anonvolatile memory configured to store at least a long term encryptionkey (LTK), an anti-tracking (A-T) count, and a nonce value; and acontroller configured to establish wireless encrypted connections,receive a communication from a peer device that includes a peer hashedanti-tracking count (HATC), generate at least one local HATC by hashingat least the LTK and a changed A-T count value, the changed A-T countvalue varying from the stored A-T count value by a predetermined amount,authenticate the received peer HATC with the at least one local HATC,not communicate with the peer device if the peer HATC is notauthenticated, and communicate with the peer device if the peer HATC isauthenticated.
 10. The device of claim 9, wherein the nonvolatile memoryand controller are formed with a same integrated circuit substrate. 11.The device of claim 9, wherein: the controller includes counter circuitsconfigured to update the A-T count in the nonvolatile memory, andarithmetic-logic circuits configured to execute a hash function forhashing at least the LTK and a changed A-T count value.
 12. The deviceof claim 9, further including: radio circuits configured to receive andtransmit packets from the peer device that are compatible with at leastone wireless standard; wherein the at least one wireless standard isselected from the group of: a Bluetooth standard including Bluetooth LowEnergy, and a WiFi Aware standard.
 13. The device of claim 9, wherein:the controller further includes nonce generator circuits configured togenerate nonce values; and the arithmetic logic circuits are configuredto execute the hash function on at least the changed A-T count, the LTK,and the nonce value.
 14. The device of claim 9, wherein: the controlleris configured to generate a first local HATC with a first changed A-Tcount that is the stored A-T count value incremented by one, andgenerate a second local HATC with a second changed A-T count value thatis the stored A-T count value incremented by two; and authenticating thereceived peer HATC with the first local HATC or the second local HATC.15. A system, comprising: a first wireless device that includes circuitsconfigured to store at least a long term encryption key (LTK), ananti-tracking (A-T) count, and a peer nonce value for a peer device,establish a wireless encrypted connection with at least the LTK, receivea communication from a peer device that includes a peer hashedanti-tracking count (HATC), generate at least one local HATC by hashingat least the LTK and a changed A-T count value that varies from thestored A-T count value by a predetermined amount, authenticate thereceived peer HATC with the at least one local HATC, not communicatewith the peer device if the peer HATC is not authenticated, andcommunicate with the peer if the peer HATC is authenticated; and anantenna system configured to transmit and receive packets according toat least one wireless standard.
 16. The system of claim 15, furtherincluding: a peer wireless device that includes peer circuits configuredto store the LTK, the peer A-T count, and the peer nonce, generate thepeer HATC by hashing at least the LTK, the peer nonce, the changed A-Tcount value, and transmit a packet that includes the peer HATO; and apeer antenna system configured to transmit the packet according to theat least one wireless standard.
 17. The system of claim 16, furtherincluding: the first wireless device circuits are further configured toin response to the peer HATC being authenticated, re-establishing awireless encrypted connection with at least the LTK, and in response toreceiving a communication from the peer over the re-established wirelessencrypted connection, changing the stored A-T count; and the peerwireless device is configured to, in response to receiving acommunication from the first device over the re-established encryptedconnection, changing its stored peer count value.
 18. The system ofclaim 17, wherein: the first wireless device circuits changing thestored A-T count includes incrementing the stored A-T count; and thepeer wireless device changing its stored A-T count includes incrementingits stored peer A-T count.
 19. The system of claim 15, wherein: thefirst wireless device circuits are configured to generate a first localHATC with a first changed A-T count that is the stored A-T count valueincremented by one, and generate a second local HATC with a secondchanged A-T count value that is the stored A-T count value incrementedby two; and authenticating the received peer HATC with the first localHATC or the second local HATC.
 20. The system of claim 15, wherein thewireless encrypted connections are compatible with at least one wirelessstandard selected from the group of: Bluetooth, including Bluetooth lowenergy, and WiFi Aware.